There are a plurality of networks of different types, i.e., networks with different protocols, such as IPv4 (Internet protocol version 4) and IPv6 (Internet protocol version 6). Some of these networks are widely used, such that they cover a large area (e.g., IPv4 Internet). Other networks are only applied on isolated spots (e.g., IPv6 Internet, which is currently only used on isolated sites). It is desired to connect these isolated networks of the same type. For this connection, a “tunnel” concept has been proposed. A tunnel is a virtual link between two network nodes. That is, tunnelling works by encapsulating a protocol of the first network within packets carried by the second network. In case of IPv6 and IPv4 this means that IPv6 protocol is embedded within the IPv4 packets. Another example is Virtual Private Network (VPN). In this case, organizations are enabled to use the Internet to transmit data across the VPN. This is performed by embedding the VPN network protocol within the TCP/IP packets carried by the Internet. Hence, such tunnels are playing important roles in virtual internetworking. Heretofore, configuration of the tunnels was carried out manually, which is troublesome and requires a lot of work. To overcome the low efficiency of such a manual tunnel configuration, some automatic tunnelling approaches, such as Tunnel Broker (TB) (see, e.g., A. Durand, P. Fasano, D. Lento, “IPv6 Tunnel Broker”, RFC 3053, January 2001) and 6to4 implicit stateless tunnel (see. e.g., B. Carpenter, K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, February 2001), have been developed and deployed in IPv6 networking. In VPN (Virtual Private Network) techniques, tunnels combine all the nodes scattering among geographically different sites as a uniform logical network.
The connection mechanism of IPv6 domains via IPv4 clouds mentioned above is a stateless solution for automatic tunnelling IPv6 “islands” separated by IPv4 “seas”, in virtue of a specified IPv6 address format. Logically, each pair of peer sites in 6to4 is connected directly in the virtual network sense, i.e. is not any IPv6 relay between the peers and the virtual network (VN) forms a full-mesh topology. As IPv6 packets are sent from each peer to another via IPv4 routers only, the performance of an IPv6 session is the same as that on the IPv4 end-to-end path between the corresponding nodes.
In the Tunnel Broker approach, the stateful broker services make the addressing flexible. However, in the Tunnel Broker system, a Tunnel Server (TS) of a relay centre for a group of Tunnel Clients is provided. Each Tunnel Client (TC) has a default route to the other part of the IPv6 world via the Tunnel Server, and each pair of Tunnel Clients must communicate via the Tunnel Server's relay definitely, even when directly tunnelling the two Tunnel Clients may be far better. Then the performance of an IPv6 session between two Tunnel Clients depends on end-to-end behaviour between the Tunnel Server to both of them.
Both methods mentioned above do not provide the capability of dynamic tunnel change according to the performance behaviour of virtual link (tunnel).
However, up to now, no existing tunnel technique includes consideration of the performance problem, i.e. matching the virtual networking process to the performance and its variation over the IPv4 infrastructure.